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(54) Mobile packet communication with prioritised 


(57) A mobile communication system with a packet 
switching function which enables sharing of radio re- 
sources among mobile stations, wherein a mobile sta- 
tion which has generated a request for communication 
quality assurance periodically sends a packet for re- 
questing preferential use of a radio channel in order to 
prevent timeout of the state transition timer timeout of 
which would cancel radio channel assignment to the 
mobile station and bring it into a dormant slate if a cer- 


tain period elapses without transmission or reception of 
a signal, so that it can remain in the active state and hold 
the radio channel continuously. In addition, when the 
mobile station requesting communication quality assur- 
ance moves from one cell to another or requests radio 
channel assignment, the base station controller controls 
the radio base station so that the mobile station can be 
assigned a radio channel by sending a priority request 
packet. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] This invention relates generally to mobile com- 
munication systems, and particularly to a mobile com- 
munication methods for mobile stations, base station 
controllers and packet data service nodes. 
[0002] Effective use of radio channels in mobile com- 
munication systems can be achieved using packet 
switching techniques to enable sharing of a radio chan- 
nel among mobile stations. According to such tech- 
niques, when a request for signal transmission or recep- 
tion is generated, each mobile station uses the assigned 
radio channel shared with other mobile stations to trans- 
mit or receive signals in the form of packets. Further, 
when there is no such request, the radio channel is freed 
to enable its use by another mobile station. Moreover, 
in such techniques, radio channel assignment to mobile 
stations in which no packet transmission or reception 
has taken place for a certain time period are canceled. 
[0003] In conventional mobile communication sys- 
tems, if a request for signal transmission or reception 
occurs in a mobile station canceled for radio channel 
assignment, it is necessary to begin with assignment of 
a radio channel to that mobile station. But there is a pos- 
sibility that there is no free radio channel. In addition, in 
a mobile communication system, as a mobile station 
moves from one cell to another, the mobile station must 
be assigned a radio channel by the radio base station 
controlling the destination cell but again there is a pos- 
sibility that there is no free radio channel. This may lead 
to problems in communication quality assurance for 
communications that require high reliability, such as 
electronic commerce. 

[0004] What is needed are techniques for maintaining 
an assigned radio channel between mobile and non mo- 
bile units in a packet based mobile communications sys- 
tems. 

SUMMARY OF THE INVENTION 

[0005] According to the present invention techniques 
for maintaining an assigned radio channel between a 
mobile unit and a non mobile unit when preferential use «s 
of the radio channel is desired are provided. Embodi- 
ments according to the invention can maintain the radio 
channel regardless of the packet transmission or recep- 
tion interval., and can further ass ign radio channels pref- 
erentially according to requests for radio channel as- & 
signment. Techniques according to the invention can be 
embodied in a mobile unit, such as a mobile station, cell 
phone : pager and the like, a non-mobile unit, such as a 
base station controller, and the like, or a packet data 
service node. 5f 
[0006] In a representative embodiment according to 
the present invention, a mobile station requesting pref- 
erential use of a radio channel periodically sends a pri- 


ority request to a radio base station, which, upon receiv- 
ing the priority request, periodically sends a reply to the 
priority-requesting mobile station. This means that sig- 
nal reception and transmission take place periodically 
5 or at regular time intervals between the priority-request- 
ing mobile station and the radio base station; therefore, 
if this interval is shorter than a time allowed before can- 
cellation of radio channel assignment, the mobile station 
can keep being assigned the radio channel. 
10 [0007] In addition, according to this invention, the 
base station controller which controls the radio base sta- 
tion has means to separately control preferred mobile 
stations using radio channels preferentially and other 
mobile stations, or non-preferred mobile stations, and 
is also to control the non-preferred mobile stations in the 
order of length of time which has elapsed after their 
transmission to, or reception from, the radio base station 
of the last signal (radio channel non-use time). Thus, If 
mobile stations requesting preferential use of a radio 
20 channel request assignment of a radio channel and 
there is no free radio channel in the radio base station, 
the base station controller can release radio channel as- 
signments from non-preferred mobile stations, in the de- 
scending order of length of their radio channel non-use 
25 time, and re-assign the released radio channels to the 
priority-requesting mobile stations. 
[0008] Numerous benefits are achieved by way of the 
present invention over conventional techniques. 
[0009] An object of this invention is the provision of a 
1 mobile station which has means to keep an assigned 
radio channel, when preferential use of a radio channel 
is required, regardless of the packet transmission or re- 
ception interval, and also to be assigned preferentially 
a radio channel when ft requests radio channel assign- 
ment. 

[0010] A further object of the invention is the provision 
of a base station controller having means to keep as- 
signing a radio channel to a mobile station which has 
requested preferential use of a radio channel, regard- 
less of the packet transmission or reception interval and, 
when a priority-requesting mobile station requests as- 
signment of a radio channel, assign It a radio channel 
preferentially. 

[001 1] Another object of the invention is the provision 
of a packet data service node having means to enable 
preferential use of a radio channel by a mobile station 
which has requested preferential use of a radiochannel. 
[001 2] A further object of the invention is the provision 
of a mobile communication method that can keep as- 
signing a radio channel to a mobile station which has 
requested preferential use of a radio channel, regard- 
less cf the packet transmission or reception interval and, 
when e priority-requesting mobile station requests as- 
signment of a radio channel, assign it a radio channel 
preferentially. 

[0013] These and other benefits are described 
throughout the present specification. A further under- 
siandinc c? the nature and advantages of the invention 
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herein may be realized by reference to the remaining 
portions of the specification and the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

{0014] 

Fig. 1 shows an example of a mobile data commu- 
nication system according to this invention. 
Fig. 2 shows an example of logical connection map- 
ping between mobile station and PDSN. 
Fig. 3 shows an example of threshold when radio 
channel assignment is made to mobile station. 
Fig, 4 shows an example of the structure of a mobile 
station. 

Fig. 5 shows an example of the structure of a base 
station controller. 

Fig. 6 shows an example of the PDSN structure. 
Fig. 7 shows resource state transition in packet 
switching. 

Rg. 6 is a flowchart showing a sequence for a mo- 
bile station to hold a radio channel. 
Rg. 9 shows the relationship among the state tran- 
sition timer, PPP keep alive timer and OoS key 
stale. 

Fig. 10 is a flowchart showing a sequence for a mo- 
bile station to be assigned a radio channel prefer- 
entially to continue to use the channel. 
Rg. 11 is a flowchart showing a processing se- 
quence in PDSN which has received a QoS request. 
Rg. 12 shows an example of the structure of a mo- 
bile station information table in the memory cache 
of PDSN. 

Rg. 13 shows an example of the structure of a link 
layer connection control table in the memory cache 35 
of BSC. 

Rg. 14 shows an example of the structure of a chan- 
nel code control table in the memory cache of BSC. 
Rg. 15 Is a flowchart showing a processing se- 
quence for BSC which has accepted an instruction *o 
for priority processing. 

Rg. 16 is a flowchart showing a processing se- 
quence for radio channel assignment in BSC when 
the priority-requesting mobile station requests radio 
channel assignment. 45 
Figs. 17-20 show structures of a example request 
packets. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

50 

[0015] Effective use of radio channels in mobile com- 
munication systems can be achieved using packet 
switching techniques to enable sharing of a radio chan- 
nel among mobile stations. According to such tech- 
niques, when a request for signal transmission or recep- 5* 
tion is generated, each mobile station uses the assigned 
radio channel shared with other mobile stations to trans- 
mit or receive signals in the form of packets. Further 


when there is nosuch request, the radio channel is freed 
to enable its use by another mobile station. Moreover, 
in such techniques, radio channel assignment to mobile 
stations in which no packet transmission or reception 
5 has taken place for a certain time period are canceled. 
For further information about packet wireless communi- 
cation, reference may be had to a publication by 3rd 
Generation Partnership Project 2 (3GPP2), entitled, 
"Stage 3 description of Ax interface rev.1 (3gpp2-ACO- 
10 1 9990927-0),* the entire contents of which are incorpo- 
rated herein by reference for all purposes. 
[0016] In conventional mobile communication sys- 
tems, if a request for signal transmission or reception 
occurs in a mobile station canceled for radio channel 
assignment, it is necessary to begin with assignment of 
a radio channel to that mobile station but there Is a pos- 
sfoility that there is no free, radio channel. In addition, 
in a mobile communication system, as a mobile station 
moves from one cell to another, the mobile station must 
*0 be assigned a radio channel by the radio base station 
controlling the destination cell but again there is a pos- 
sibility that there is no free, radio channel. This may lead 
to a serious problem in communication quality assur- 
ance for communications that require high reliability, 
& such as electronic commerce. 

[0017] Embodiments according to the invention pro- 
vide mobile communication systems, methods and ap- 
paratus having the capability to maintain an assigned 
radio channel. Responsive to a request by a mobile sta- 
30 tion for preferential use of a radio channel, in which the 
mobile station periodically sends a priority request to a 
radio base station, which, upon receiving the priority re- 
quest, periodically sends a reply to the priority-request- 
ing mobile station. This mechanism provides that signal 
reception and transmission take place periodically or at 
regular time intervals between the priority-requesting 
mobile station and the radio base station; therefore, If 
this interval is shorter than a time allowed before can- 
cellation of radio channel assignment: the mobile station 
can keep being assigned the radio channel. 
[0010] In addition, according to this invention, the 
base station controller which controls the radio base sta- 
tion can separately control preferred mobile stations us- 
ing radio channels preferentially and other mobile sta- 
tions, or non-preferred mobile stations. Further, the 
base station controller can control the non-preferred 
mobile stations in the order of length of time which has 
elapsed after their transmission to : or reception from, 
the radio base station of the last signal (radio channel 
non-use time). Thus., if mobile stations are requesting 
preferential use of a radio channel request assignment 
of a radio channel and there is no free radio channel in 
the radio base station, the base station controller can 
cancel radio channel assignments to non-preferred mo- 
bile stations : in the descending order of length of their 
radio channel non-use time, for example, and re-assign 
the freed radio channels tc the priority* requesting mo- 
bile stations. 
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[0019] Fig. 1 shows the structure of a mobile data 
communication system 101 according to this invention. 
The system comprises of a radio access network (here- 
inafter called RAN) 110 and a packet core network 108, 
where the RAN, comprises of mobile stations (hereinaf- 
ter called MS) 1 02, base stations (hereinafter called BS) 

1 04 (1 04A-1 04F) which exchange signals with MS 1 02, 
located in service areas called cells 103 (103A-103F); 
and base station controllers (hereinafter called BSC) 

105 (105A-105D) which comprehensively control the 
base stations 104, while the packet core network 109 
comprises of packet data service nodes (hereinafter 
called PDSN) 106 (106A, 106B), which are connected 
with the radio access network 1 1 0 and have an IP packet 
routing function; a home agent (hereinafter called HA) 
108 which enables mobile stations to move between 
PDSN 106A and 106B; gateway routers 107 (107B and 
1 07C) for connection with external networks such as the 
Internet and an in-house LAN; and a router 1 07A which 
connects said gateway routers and PDSN 106. 
[0020] Fig. 2 shows an example of mapping of con- 
nections between MS 1 02 and PDSN 1 06. A radio chan- 
nel 203 is set between MS 102 and BSC 105 and a link 
layer connection 202 is set between BSC 105 and PD- 
SN 106 so that PPP connection 201 is mapped on both 
the connections . Base station controller 1 05 controls the 
change in mapping of radio channel 203 and link layer 
connection 202 which occurs as a mobile station moves 
from one BS 104 to another BS 104, while PDSN 106 
controls the change In mapping of PPP connection 201 
and link layer connection 202 which occurs as a mobile 
station moves from one BSC 105 to another BSC 105. 
[0021] Fig. 4 shows an example of the structure of MS 
102 according to this invention. Mobile station 102 com- 
prises of an antenna 404; a transmission/reception 
processor 403, which performs encoding and decoding 
to transmit or receive data through the antenna; a user 
interface section 401 ; a control section 402 which con- 
trols the user interface, carries out protocol processing 
of data and interfaces with the transmission/reception 
processor; and a battery 415. The user interface section 
401 is composed of a display 407 ( a switch section 4 1 6. 

a speaker 413 and a microphone 414. The switch sec- 
tion 416 contains a power switch to turn on and off the 
power, 406: dial keys for entry of numerals and charac- 
ters: 409: a select key which executes dialing, enables 
the commencement of talking with incoming lines and 
starts data service, 410: scroll keys to scroll the display. 
411; and a OoS key to request communication quality 
assurance in accordance with inputs made by the user - 
or instructions from the control section 402 which de- 
pends on the service used by the user, 412. The control 
section 402 comprises of a CPU 41 8 : a ROM 406 end 
a RAM 405 : where the CPU 418 starts the service de- 
pending on the request input from the switch section i 
416, performs transmission/reception traffic protocol 
processing related to the service and controls the dis- 
play, the ROM406 stores the programs concerned and 


the RAM405 stores state information necessary for pro- 
tocol processing and radio resource state Information. 
A bus 417 interconnects 401, 402 and 403 In order to 
allow them to exchange data and programs. 
* [0022] Fig. 5 shows a representative structure for an 
example Base station controller, such as BSC 105, In a 
particular embodiment according to the present inven- 
tion. Base station controller 105 comprises of a control 
section 501 , a base station l/F port section 510 and a 
*o network l/F section 511 . These sections are intercon- 
nected with each other through a packet bus 509. The 
control section 501 comprises of the following: a proc- 
essor 503, which controls radio resources for each BS 
104 and executes conversion between link layer con- 
's nection202 and radio channel203; a memory 502 which 
stores the programs concerned; a memory cache 504 
which contains tables to control radio chajweicodes as 
radio channel identifiers and tables tor each MS to con- 
trol radio channel information and radio resource states, 
20 a buffer memory 505 which temporarily stores data to 
be transmitted; a buffer memory controller 506; a hard 
disk 507; and a hard disk cont roller508. The control sec- 
tion 501 is connected to base station 104 (four base sta- 
tions in this embodiment) through the base station l/F 
& port section 510. Further, control section 601 Is connect- 
ed to POSN106 through the network l/Feectton S11 . 
[0023] Fig. 6 shows a representative structure lor an 
example PDSN in a particular embodiment according to 
the present invention. Packet data service node 106A 
so comprises a control section 601 and two of more routing 
sections 602, which are interconnected through a pack- 
et bus 603. The control section 601 comprises of the 
following: a memory 605A which stores a program to 
create packet routing tables; a processor 610A which 
35 executes that program; a memory cache 611 A which 
contains packet routing tables and information about 
mobile stations, for example; a buffer memory 606A 
which stores packets, 505; a buffer memory controller 
607A which comprises a function for DMA transfer of 
*o packets to and from the buffer memory 606A of the rout- 
ing section 602, and a function of packet bus control; a 
hard disk controller 608: and a hard disktXX). 
[0024] The packet routing table created by the proc- 
essor 61 OA is used to control mobile IP processing; (in- 
'5 eluding processes of collecting position information for 
the Mobile Stations 1 02 present in the mobile data com- 
munication system 101 and notifying Home Agent 108), 
establishing a PPP connection 201 with MS 102, estab- 
lishing a link layer connection 202 with BSC 105, asso- 
>o dating a mobile IP tunneling and PPP connection 201 , 
and associating a PPP connection 201 and link layer 
connection 202. 

[0025] The routing section 602 comprises a processor 
61 OB which executes packet transmission between HA 
5 1 06 and BSC 1 05 according to the packet routing table 
created by the control section. Further, routing section 
602 can include a memory 605B; a buffer memory 606B; 
a buffer memory cent roller 607B: a memorycache€1 IB 
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which contains the packet routing table created by the 
control section, a port control section 612 which con- 
nects another router 107; and an internal bus. In this 
figure, one port control section 612 supports four ports 
and, In this embodiment, connections with more than 
one router 107 and more than one BSC 105 are made 
through these ports. 

[0026] Fig. 7 shows a representative radio resource 
state transition diagram of packet switching in a partic- 
ular embodiment according to the present invention. 
Fig. 7 Illustrates three states: a null state 701 , in which 
MS 102 is not connected to the mobile data communi- 
cation system 1 01 (the power is off or data communica- 
tion is impossible); an active state 702, in which MS 1 02 
is connected to the mobile data communication system i 
101 and is assigned a radio channel; and a dormant 
state 70S, in which MS 1 02 is connected to the mobile 
data communication system 101 but is not assigned a 
radio channel. With MS 1 02 in its active state 702, if a 
certain time has elapsed without transmission or recep- * 
tion of a signal, the radio channel assignment to the Mo- 
bile Station is canceled and the state shifts into the dor- 
mant state 703. In this specific embodiment of a mobile 
data communication system, mobile stations in the ac- 
tive state 702 can exchange packets with BS 1 04. while, £ 
in order to transmit or receive packets, mobile stations 
in the null state 701 or dormant state 703 request BSC 
1 05 to assign them radio channels using random access 
channels or control channels. Upon having been as- 
signed radio channels under the control of BSC 105, the * 
mobile station can shift into the active state 702. A MS 
102 which has failed to shift into the active state can 
request radio channel assignment again after a certain 
period has elapsed. 

[0027] To enable state transitions as shown in Fig. 7, 33 
the control section 501 of BSC 105 is provided with a 
statetransition timer 901Bfor each MS 102 so that when 
BSC 1 05 transmits a signal to, or receives a signal from, 
a MS 102, it restarts the state transition timer 90 IB cor- 
responding to that Mobile Station. This process is illus- 40 
trated graphically in Fig. 9. When this timer times out (a 
preset time expires), BSC 1 05 releases the radio chan- 
nel from the corresponding MS 102 : which then shifts 
from the active state 702 to the dormant state 703. In 
conventional mobile data communication systems, 
even if a mobile station is making communications 
which require high reliability, such as real-time applica- 
tions and electronic commerce, if a certain lime period 
has elapsed without any signal transmission or recep- 
tion, resource state transition into the dormant state, i. so 
e., stale 703, occurs and the radio channel is released. 
Furthermore, since free radio channels are not always 
available, there may be a case in which the communi- 
cation service concerned will become unavailable. 
[0028] To overcome problems inherent to convention- ss 
al technologies , when preferential use of a radio channel 
is needed, embodiments according to the present inven- 
tion can inhibit stale transitions, such as irom the active 


state 702 to the dormant state 703, responsive to the 
user pushing the QoS key 412 of MS 102 or the control 
section 402 of MS 102 giving an instruction for prefer- 
ential use of a radio channel, for example. Depending 
5 on the service in use by the user, in specific embodi- 
ments, the MS 102 can hold the radio channel continu- 
ously. 

[0029] Fig. 8 shows a flowchart of a representative 
processing of a priority request input sequence in a par- 
10 ticular embodiment according to the present invention. 
The processing illustrated by Fig. 8 can take place in 
MS 102, for example, in order to continuously hold the 
radio channel assigned by BS 104. When the user in- 
puts to the QoS key 412, or when the control section 
f5 402 gives an instruction for preferential use depending 
on the service or application in use by the user, then, as 
illustrated by a step 801 , the MS 1 02 turns on the OoS 
key. In a step 802, MS 1 02 can transmit PPP keep alive 
packet at regular intervals in order to prevent BSC 105 
*> from releasing the radio channel from the MS. Structure 
of the PPP keep alive packet 1800 is shown in Fig.16. 
The PPP keep alive packet has MS ID field 1801 and 
packet ID field 1 802 indicating that the packet is a PPP 
keep alive packet. If the communication system adopts 
5 CDMA scheme and the network can recognize the MS 
from the spreading code used in the packet, the MS ID 
field 1 801 is not necessary. Then, in a step 803, MS 1 02 
sets the PPP keep alive timer902, provided in its control 
section 402, for measuring PPP keep alive packet trans- 
> mission intervals, to a value smaller than the value set 
on the wireless channel state timer 901 A. Wireless 
channel state timer 901 A is in the Control Unit 402 in 
the MS 102, and measures the period between the last 
transmission/reception to/from BSC 105 and the re- 
lease of assigned wireless channel by BSC 1 05. There- 
fore the Wireless channel state timer 901 A measures in 
the same way as the State transfer timer 901 B as a re- 
sult. 

[0030] Fig. 9 shows an example of relationship among 
the wireless channel state timer 901 A, the state transi- 
tion timer 901 B PPP keep alive timer 902 and OoS key 
state. With the OoS key 412 on, because the PPP keep 
alive timer 902 is set lo a value smaller than the wireless 
channel state timer 901 A, the PPP keep alive timer 902 
times out before timeout of the state transition timer 
901 B which would cause the release of the radio chan- 
nel from MS 1 02 and the change of the state of MS 1 02 
from the active state 702 to the dormant state 703 . When 
the PPP keep alive timer 902 has timed out but the wire- 
less channel slate timer 901 A has not timed out yet. MS 
102 sends 6 PPP keep alive packet. As BSC 105 re- 
ceives the PPP keep alive packet, it sends an acknowl- 
edgement packet to MS 102. Structure of the acknowl- 
edgement packet 1S00 for the PPP keep alive packet is 
shown in Fig.1 9. The PPP keep alive packet has MS ID 
field 1901 and packet ID field 1902 indicating that ihe 
packet is an acknowledgement packet. If the communi- 
cation system adopts CDMA scheme and the network 
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can recognize the MS from the spreading code used in 
the packet, the MS ID field 1 902 is not necessary. Mobile 
station 102 restarts the wireless channel state timer 
901 A upon transmitting the PPP keep alive packet or 
receiving the acknowledgement packet from BSC 1 05, s 
while BSC 105 restarts the state transition timer 901 B 
upon receiving the PPP keep alive packet from MS 1 02 
or transmitting the acknowledgement packet to MS 102, 
so that release of radio channel can be avoided. 
[0031] When the user inputs to the QoS key 412 again io 
at the end of use of service or when the control section 
402 gives an instruction for cancellation of preferential 
use of the radio channel at the end of use of service, the 
QoS key is turned off in a step 804. Then, in a step 80S, 
the PPP keep alive timer 902 is set to a normal value, w 
or a value larger than the one set on the wireless chan- 
nel state timer 901 A. If a certain period has elapsed with- 
out any packet transmission or reception, the state tran- 
sition timer 901 B times out earlier than the PPP keep 
alive timer 902, the wireless channel is release from the so 
MS 1 02, and the state of the MS 1 02 transfers Into the 
dormant state 703. After the transition into the dormant 
state, when the PPP keep alive timer 902 times out, MS 
102 does not send a PPP keep alive packet as long as 
the wireless channel state timer 901 A is still time out. 25 
[0032] When MS 1 02 shifts from its dormant state into 
its active state, or when MS 1 02 moves from one cell to 
another, it requests radio channel assignment from BSC 
1 05 by the use of a random access channel or control 
channel. Fig. 1 7 shows a representative composition of so 
a radio channel assgnment request packet as an ex- 
ample. Here, 1701 represents the MS ID number that is 
requesting channel assignment and 1702 represents 
the BS ID number to which the MS is requesting the 
channel assignment. A field 1 703 represents the trans- ss 
mission power level in a perch channel (hereinafter 
called BCCH) through which BS 1 04 is transmitting sig- 
nals, while field 1704 represents the interference level 
in the uplink channel. A field 1705 denotes the received 
power of BCCH measured in MS 1 02 and 1 706 the re- to 
ceived S IR of BCCH. A field 1 707 denotes the requested 
transmission speed of the downlink channel and 1708 
that of the uplink channel. Some specific embodiments 
may comprise other informational fields . or may omit 
one or more of the fields illustrated in Fig. 17 without '5 
departing from the scope of the claimed invention. When 
MS 102 moves from one cell to another BSC 105 can 
automatically catch the radio channel assignment re- 
quest due to that movement without part or all of the 
information shown in Fig. 1 7 f because BSC 105 knows 50 
the service and the transmission speed of channels 
used by that MS. 

[0033] In a representalive embodiment according to 
the present invention, base station controllers periodi- 
cally collect from BS 104 communication quality infor- 
mation for each cell : suchas des ired signal level (RSSI). 
interference signal level (ISSI). desired-to-undesired 
signal ratio (SIR) end frame error rate (FER), and stores 


it in the memory 502. As BSC 105 receives the request 
for radio channel assignment from MS 102, it decides 
whether to assign a radio channel to that MS 102, de- 
pending on whether the predicted interference level is 
within a predetermined allowable range. The Informa- 
tion on the cell in the memory 502, as well as information 
included in the radio channel assignment request pack- 
et, such as the requested transmission speed, SIR of 
BCCH and uplink channel interference level, are used 
for the processor 503 to predict how much the commu- 
nication quality will deteriorate if a radio channel is as- 
signed to the assignment requesting mobile station. Al- 
ternatively, theBSClOS can specifically predict what the 
interference level will be if radio channel assignment to 
the requesting mobile station takes place. Also, in spe- 
cif ic embodiments, instead of using an interference lev- 
el, the base station controller miayjdedde whetherto as- 
sign a radio channel depending on whether the trans- 
mission speed total for all active mobile stations con- 
nected to the base station to which the MS is requesting 
radio channel assignment, exceeds a preset threshold. 
For further description of communication quality infor- 
mation, reference may be had to a publication entitled, 
"ARIB STD-T53, a standard for CDMA portable mobile 
telephone systems established by the Association of 
Radio Industries and Businesses (ARIB)" the entire 
contents of which are incorporated herein by reference 
for all purposes. 

[0034] Fig. 10 shows a flowchart of a representative 
priority request input sequence in a particular embodi- 
ment according to the present invention. The MS 102 
can use such a sequence to enable the user requesting 
preferential use of a radio channel to be assigned a radio 
channel preferentially andto be able to use the assigned 
channel continuously. When the user Inputs to the QoS 
key 412, or when the control section 402 gives an in- 
struction for preferential use of a radio channel, depend- 
ing on the service selected by the user, then, in a step 
1 001 . MS 1 02 transmits a QoS requesting packet to the 
PDSN106 connected to it. If the prior MS 102 moves 
between cells and the BSC 1 05 has already recognized 
the MS as the MS requesting preferential channel as- 
signment, the QoS requesting packet transmission is 
not necessary for that prior MS. Structure of the QoS 
requesting packet 2000 is shown in Fig.20. The QoS re- 
questing packet has MS ID field 2001 and packet ID field 
2002 indicating that the packet is a QoS requesting 
packet If the communication 6ystem adopts CDMA 
scheme and the network can recognize the MS from the 
spreading code used in the packet, the MS ID field 2001 
is not necessary. Having received the QoS requesting 
packet and decided whether or not to permit preferential 
channel management for MS 102 ; the PDSN 106 trans- 
mits e reply which is awaited by MS 102 in a step 1002. 
If. in step 1003 : the reply is determined to be affirmative, 
then in e step 1 004 , the QoS key is turned on and in a 
step 1005. a request for radio channel assignment is 
sent to BSC 105. When the radio channel assignment 
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request is made due to movement of MS 1 02 from one 
cell to another, BSC 105 may automatically knows the 
radio channel assignment request. If BSC 105 does not 
permit radio channel assignment, such request may be 
issued again after a certain period of time has elapsed. 
If BSC 105 permits radio channel assignment, as de- 
scnbed herein with reference to Fig. 6, then in a step 
1006, the MS 102 sends a PPP keep alive packet at 
reguiar intervals in order to hold the PPP connection 
201 . Then, in a step 1 007, the PPP keep alive timer 902 
Is set to a value smaller than the wireless channel state 
timer 901 A. With this setting, MS 102 can hold its active 
state 702. If the subscription contract for MS 102 pre- 
vents PDSN 106 from permitting preferential channel 
management then, in a step 1008, the display of that 
mobile station MS 102 shows that the OoS function is 
invalid. If that is the case, then in a step 1009, the MS 
1 02 requests radio channel assignment from BSC 1 05, 
as an ordinary mobile station, or a mobile station which 
is not preferentially controlled. If It is not assigned a radio 
channel, It may make the same request again after a 
certain period of time. If it is assigned a radio channel, 
the MS 102 does not send a PPP keep alive packet be- 
cause it is not subject to preferential control. When the 
user inputs to the QoS key 412 again at the end of use 
of service, or when the control section 402 gives an in- 
struction for cancellation of preferential use of the radio 
channel at the end of use of service, then in a step 604, 
the QoS key Is turned off. Then, in a step B05, the PPP 
keep alive timer 902 is set to a normal value, or a value 
larger than the one set on the wireless channel state 
timer 901 A. 

[0035] Fig. 11 shows a flowchart of representative 
processing by a packet data service node responsive to 
a OoS request from a mobile station in a particular em- 
bodiment according to the present invention. In Fig. 11 , 
PDSN 106 has received a OoS request from MS 102. 
Fig. 11 illustrates processing that is carried out at the 
processor 61 OA in the control section 601 of PDSN 1 06. 
After receiving the OoS request, PDSN 106 searches 
the mobile station information table 1201 corresponding 
to the requesting mobile station in a step 1101 . Fig. 12 
shows a representative structure of a mobile station in- 
formation table 1201 as an example. The mobile station 
information table is located in the memory cache 611 A 
of PDSN 106. The table 1201 contains a mobile station 
unique identifier obtained from the subscrtoer informa- 
tion and a temporary mobile station identifier assigned 
after connection with the mobile communication net- 
work; authentication and confidential information; IP ad- 
dress in use by mobile station; positional information: 
home network identifier: home agent address: and OoS 
contract service information 1202 comprising of infor- 
mation on existence of a priority processing contract 
1203 and contract transfer throughput 1204. Some spe- 
cific embodiments may comprise other informational 
fields, or may omit one or more of the fields illustrated 
in Fig. 12 without departing from the scope of the 
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claimed invention. 

[0036] After searching the mobile station information 
table, in a 6tep 1102 : the PDSN 106 checks the OoS 
service information 1202 to see if the mobile station is 
under the contract for priority processing. If the mobile 
station is not, then, in a step 11 06, It informs the MS 102 
that preferential control is unavailable. On the other 
hand, if it is under the contract for priority processing, 
then in a step 1103, the PDSN 106 gives an instruction 
for priority processing of the MS 102 to the BSC 105 
connected to the MS 1 02. In a step 1104, the BSC 105 
returns a reply for confirmation, and in a step 1105, no- 
tifies the mobile station that it can be preferentially con- 
trolled. 

[0037] Base station controller 105 is provided with a 
link layer connection control table 1301 for each mobile 
station in order to control mapping of link layer connec- 
tion 202 and the radio channel 203 assigned to the MS 
102. Fig. 13 shows a representative structure of a link 
layer connection control table 1301 as an example. Lo- 
cated in the memory cache 504 of BSC 105, the link 
layer connection control table 1301 comprises a link lay- 
er connection identifier; mobile station IP address; re- 
source state information 1302; uplink channel code and 
downlink channel code to identify the radio channel 303; 
packet escape queue: presence or absence of priority 
request 1303; uplink channel transmission speed 1304; 
downlink channel transmission speed 1305; uplink 
channel SIR 1306; downlink channel SIR 1307; and a 
control pointer. Some specific embodiments may com- 
prise other informational fields, or may omit one or more 
of the fields illustrated in Fig. 13 without departing from 
the scope of the claimed invention. 
[0038J The BSC 105 is also provided with a channel 
code control table 1401 for each of the cells 103 under 
the control of BS 1 04 in order to control the radio channel 
codes in use and enable preferential channel manage- 
ment. Fig. 14 shows a representative structure of a 
channel code control table 1401 as an example. The 
channel code control table 1401 , located in the memory 
cache 504 of BSC 105, comprises of two queues: one 
is a preferred mobile station control queue 1402, which 
registers link layer connection control tables 1301 for 
the MS 102 under the preferential channel manage- 
ment. The other is a normal mobile station control queue 
1403 which registers link layer connection control tables 
1301 for the MS 102 under the priority processing con- 
tract but not under the preferential channel manage- 
ment, as well as the ones not under the priority process- 
ing contract. Each time MS 1 02 transmits or receives a 
signal through a radio channel, the link layer connection 
control table 1 301 corresponding to that MS 1 02 is re- 
registered at the top of the control queue 1402 or 1403 
by the processor 503 located in the control section 501 
of BSC 1 05. Therefore, link layer connection control ta- 
bles 1301 are registered in the control queues 1402 and 
"405. from top to bottom thereof, in the ascending order 
of length of time which has elapsed after reception or 
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transmission of the final signal, or according to the rule 
that the table with the shortest non-use time is registered 
first and that with the longest non-use time is registered 
last. 

{0039] Fig. 15 shows a flowchart of representative 
processing in a base station controller which has ac- 
cepted the instruction for priority processing from a 
packet data service node in a particular embodiment ac- 
cording to the present invention. This processing is ex- 
ecuted by the processor 503 located in the control sec- 
tion 501 of BSC 1 05 responsive to an instruction for pri- 
ority processing from PDSN 106, for example. In Fig. 
1 5, a mobile station MS 1 02 is already in its active state, 
and has transmitted QoS requesting packet to PDSN 
106. The PDSN 106 has given BSC 105 an instruction 
for priority processing of the mobile station. In a step 
1 501 , base station controller 1 05 searches the link layer 
connection control table 1301 corresponding to the MS 
102 which should be processed preferentially. Then, in 
a step 1502, base station controller 1 05 turns on the pri- 
ority request 1303 in the corresponding table. In a step 
1503, this table is removed from the normal mobile sta- 
tion control queue 1403 in the channel code control table 
1 401 and re-registered at the top of the preferred mobile 
station control queue 1402. In a step 1504, the PDSN 
106 is notified of completion of processing in response 
to the priority processing instruction. 
[0040] Fig. 1 6 shows a flowchart of a representative 
control process for assigning a radio channel to a prior- 
ity-requesting mobile station preferentially in a particular 
embodiment according to the present invention. This 
processing is executed by the processor 503 in the con- 
trol section 501 of BSC 105, for example. In Fig. 16, a 
priority-requesting mobile station MS 102 is in its active 
state 702 and moves between base stations BS 104 
(cells 103), or a priority-requesting mobile station MS 
102 shifts from the null state 701 or dormant state 703 
into the active state 702. When a mobile station MS 1 02 
moves from one cell to another, this movement is de- 
tected in a step 1601. Then, in a step 1 602 : the link layer 
connection control table 1301 for that mobile station is 
removed from the channel code control table 1401 cor- 
responding to the former base station BS 103. In a step 
1603, utilizing the link layer connection control table as 
shown in Fig. 13, calculation is made for uplink and 
downlink channels separately to find the transmission 
speed total for all mobile stations in their active state 
under the control of the new BS 103 to which a radio 
channel assignment request is made; and then accord- 
ing to the radio channel assignment request packet re- 
ceived from the priority-requesting MS 1 02 or the trans- 
mission speed of the channel used by the MS 1 02 before 
its movement, it is judged whether or not a preset thresh- 
old will be exceeded if the transmission speed as re- 
quested by the priority-requesting MS 102 is assigned 
to the MS. Alternatively, judgment may be made as to 
whether the threshold as shown in Fig. 3 will be exceed- 
ed by the result of calculation from the transmission 
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speed total for each of the uplink and downlinkchannels 
in case of radio channel assignment being made to the 
priority-requesting MS 102, as well as the foterference 
signal level calculated by the processor 603. ft the 
threshold is not to be exceeded, then, In a step 1604, 
radio channel assignment is made to the MS 102 and 
the link layer connection control table 1301 Is registered 
at the top of the preferred mobile station control queue 
1 402 in the channel code control table 1 401 correspond- 
ing to the new BS102 in a step 1605. Otherwise, If the 
threshold would be exceeded, in a step 1606, a judg- 
ment is made as to whether there is a link layer connec- 
tion control table 1302 registered in the normal mobile 
station control queue 1403 In the channel code control 
table 1401 of the new BS 103. If there Is no Knk layer 
connection control table 1301 registered in the normal 
mobile station control queue 1403, It fe^rpossible to 
make radio channel assignment to the priority-request- 
ing mobile station because all radio channels are in use 
by preferred mobile stations, as indicated by step 1612. 
If there is a link layer connection control table 1 301 reg- 
istered in the normal mobile station control queue 1403, 
then in a step 1607, a judgment fe made asio whether, 
if radio channel assignments for normal or non-pre- 
ferred mobile stations whose link layer connection ta- 
bles are registered in the normal mobfle station control 
queue 1403 are all canceled and radio channel assign- 
ment is made to the priority-requesting mobile station, 
the transmission speed total will exceed the threshold. 
Alternatively, judgment may be made as to whether, by 
calculating the interference level and transmission 
speed total for the case that radio channel assignment 
for all norma! mobile stations are canceled and radio 
channel assignment is made to the priority-requesting 
mobile station, the interference level will exceed the 
threshold as shown in Fig. 3. If the transmission speed 
total or the interference level is to exceed the threshold, 
then it is impossible to make radio channel assignment 
to the priority-requesting mobile station, as indicated by 
step 1 61 2. In any case other than the above, the normal 
mobile stations whose link layer connection control ta- 
bles 1301 are registered in the normal mobile station 
control queue 1403 are canceled for radio channel as- 
signments in reverse order of registration, or on the ba- 
sis of first cancellation of last registered mobile station, 
until the transmission speed total for all mobile stations 
or the interference level comes below the threshold if 
radio channel assignment is made to the priority-re- 
questing mobile station, thus forcing them to shift into 
the dormant state, indicated by steps 1608, 1609 and 
1610. Then, in a step I6n : a radio channel freed from 
a normal mobile station or non-preferred MS is assigned 
to the priority-requesting mobile station and, in a step 
1605 ; the link layer connection control table 1301 for the 
priority-requesting mobile station is registered at the top 
of the preferred mobile station control queue in the chan- 
nel code control table corresponding to the base station 
which has made the assignment. 
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[0041] Thus, in representative embodiments accord- 
ing to the present invention, when the user or the appli- 
cation in use needs communication quality assurance, 
by having the mobile station concerned periodically 
send a packet to request preferential use of a radio 3 
channel, it is possible to prevent timeout of the state 
transition timer, which counts the timing of transition 
from the active 6tate to the dormant state, so that the 
priority-requesting mobile station can hold the radio 
channel continuously. 10 
[0042] Furthermore, the base station controller is pro- 
vided with means to separately control, for each cell, ra- 
dio channels used preferentially by preferred mobile sta- 
tions and radio channels used by normal mobile sta- 
tions, as well as means to control the radio channels in is 
use by normal mobile stations in the order of length of 
time which has elapsed after transmission or reception 
of the last signal. When a priority-requesting mobile sta- : 
tion moves from one cell to another, or when the priority- 
requesting mobile station requests radio channel as- 
signment, if there is no free channel in the cell, a normal 
mobile station among the ones in the cell which have 
been assigned radio channels is forced to be canceled 
for the radio channel assignment, in the descending or- 
der of length of time which has elapsed after transmis- 29 
sion or reception of the final signal, and the mobile sta- 
tion thus canceled is forced to shift from the active state 
into the dormant state, while the radio channel thus 
freed is assigned to the priority-requesting mobile sta- 
tion, which makes it possible that the priority-requesting 30 
mobile station can hold the radio channel preferentially 
as it moves to another cell, or can be assigned a radio 
channel preferentially when newty requesting radio 
channel assignment. 4, 
[0043] The preceding has been a description of the 35 
preferred embodiment of the invention. It will be appre- 
ciated that deviations and modifications can be made 
without departing from the scope of the invention, which 
is defined by the appended claims . 

40 

Claims 

1 . A wireless communication device for communicat- 5. 
ing with at least one other device, said wireless 45 
communication device comprising: 

a CPU, 

a memory, a first timer end a second timer 
a bus, connecting said CPU, said memory, to a 50 
communications interface; 
wherein when said wireless communications 
device requests preferential use ol a communi- 
cation channel, said first timer is set with a time: 
outvalue less than said second timer such that 55 
a periodic transmission of a priority request is 
made by said CPU via said communication in- 
terface at expiration of said first timer provided 


that said second timer has not expired. 

A communication device for communicating with a 
control station, 6aid device having a control section 
comprising: 

a CPU, 
a memory, 

a bus, connecting said CPU, said memory to a 
communications interface; 
wherein when said communication device re- 
quests preferential use of a communication 
channel, said channel having been assigned by 
said control station, said CPU periodically 
causes sending of a priority request to said con- 
trol station via said communications interface. 

A mobile station for wireless communication with a 
base station, said mobile station having a control 
section comprising: 

a CPU, 
a memory, 

a bus, connecting said CPU, said memory to a 
transmission/reception processor; 
wherein when said mobile station requests 
preferential use of a wireless communication 
channel, said wireless communication channel 
having been assigned by said base station, 
said CPU periodically causes sending of a pri- 
ority request to said base station via said trans- 
mission/reception processor. 

The mobile station of claim 3; further comprising: 

a PPP keep alive timer which begins counting 
from a time of any of a last signal transmission 
and a last signal reception; 
wherein upon timeout of said PPP keep alive 
timer, said control section causes sending of 
said base station said priority request, and re- 
starts said PPP keep alive timer. 

The mobile station as defined in claim 4, wherein, 
if said radio channel is used preferentially, 
said control section sets a counting period for said 
PPP keep alive timer to a value smaller than a chan- 
nel holding period, said channel holding period be- 
ing a time measured from any of a last signal trans- 
mission and a last signal reception, and until said 
base station cancels a radio channel assignment to 
said mobile station. 

The mobile station as defined in claim 5 T further 
comprising: 

a wireless channel state timer that counts said 
channel holding period: and wherein 
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if said wireless channel state timer reaches said 
channel holding period, said control section 
discontinues sending said priority request. 

7. A mobile station for wireless communication with a 
base station, said mobile station having a control 
section comprising: 

a CPU, 
a memory, 

a bus, connecting said CPU, said memory to a 
transmission/reception processor; 
wherein when said mobile station requests as- 
signment of a wireless channel from said base 
station, said CPU causes transmission of a 
preferential channel assignment request via 
said transmission/reception processor. 

8. The mobile station of claim 7, wherein said prefer- 
ential channel assignment request further compris- 
es an identification of a preferential channel usage 
request packet. 

9. A base station controller for controlling a base sta- 
tion, said base station communicating with at least 
one of a plurality of mobile stations, said base sta- 
tion controller comprising: 


a base station interface, connecting said base 
station controller to said base station; so 
a control section; 

a network interface, connecting said base sta- 
tion controller to a network; 
a packet bus, interconnecting said base station 
interface, said network interface to said control 35 
section; 

wherein said control section receives from at 
least one of said plurality of mobile stations a 
request to use a radio channel preferentially, 
through said base station, and responsive to *o 
said priority request, transmits an acknowl- 
edgement to said mobile station. 


25 


one of a plurality of mobile stations, said base sta- 
tion controller comprising: 

a base station interface, connecting said base 
station controller to said base station; 
a control section; 

a network interface, connecting said base sta- 
tion controller to a network; 
a packet bus, interconnecting sard base station 
interface, said network interface to said control 
section; 

wherein said control section receives from at 
least one of said plurality of mobile stations a 
request to use a radio channel preferentially, 
through said base station r end responsive to 
said priority request, determines an availability 
of a channel to assignio^seidTnobfle station. 

13. The base station controller of claim 12, wherein re- 
sponsive to a request for a priority wireless channel 
assignment by a priority requesting mobile station, 
and wherein, if there are no free wireless channels, 
said control section releases a wireless channel as- 
signment from a non-priority requesting mobile sta- 
tion, and assigns said wireless channel so released 
to said priority requesting mobile station. 

14. The base station controller of daln 13, wherein 

said control section releases wireless chan- 
nels from said non-priority requesting mobile station 
that has not transmitted nor received signals for a 
longest period of time. 


10. The base station controller of claim 9 ; saidbasesta- 
tion controller further comprising: 

a stale transition timer that counts a time pe- 
riod starting from at least one of a transmission to 
said base station and a reception from said base 
station, and until a channel assigned to said mobile 
station is released. 


45 
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15. The base station controller of daim 13, wherein 
when priority requesting mobile stations, moves 
from a control area of a first base station to a control 
area of a second base station, and requests a wire- 
less channel assignment from said second base 
station, and wherein, if there are no free wireless 
channels, a control section of a base station con- 
troller that controls said second base station releas- 
es a wireless channel assignment from a non-prior- 
ity requesting mobile station, and assigns said wire- 
less channel so released to said priority requesting 
mobile station. 

16. The base station controller of claim 13, further com- 
prising a link layer connection control table for man- 
aging wireless channels used by each of said mo- 
bile stations, and 


11. The base station controller of claim 9 ; wherein said 
acknowledgement further comprises identification 
of an acknowledgement packet for said priority re- 
quest. 55 

12. A base station controller for controlling a base sta- 
tion., said base station communicating with at least 


said link layer connection control table compris- 
ing a priority management registration field, 
wherein 

said control section makes a priority manage- 
ment registration in said priority management 
registration field for said priority requesting mo- 
bile stations. 
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1 7. The base station controller of claim 1 6, further com- 
prising: 

a channel control table for registering said link 
layer connection control table for each of said base 
stations; said channel control table comprising: s 

a preferred mobile station control queue for reg- 
istering said link layer connection control table 
of a preferred mobile station which receives 
said priority channel management from said io 
base station controller, and 
a non-preferred mobile station control queue 
for registering said link layer connection control 
table of said non-preferred mobile station in as- 
cending order of length of time for which said '£ 
non-preferred mobile station left said wireless 
channel unused. 


18. The base station controller of claim 1 7, whereinsaid 
link layer connection control table includes a uplink x> 
transmission speed field, and a downlink transmis- 
sion speed field, wherein 

said control section calculates total transmis- 
sion speed of all mobile stations in a cell con- & 
trolled by said base station, and 
in case of said total transmission speed being 
over a threshold, said control section releases 
said wireless channel from said non-preferred 
mobile station whose link layer connection con- so 
trol table Is registered last in said non-preferred 
mobile station control queue. 


19. The base station controller as defined in claim 17, 
wherein 


55 


said link layer connection control table includes 
a uplink SIR field, and a downlink SIR field, 
said control section calculates total SI R in a cell 
controlled by said base station, and *o 
in case of said total SIR being over a predeter- 
mined threshold said control section releases 
said wireless channel from said non-preferred 
mobile station whose link layer connection con- 
trol table is registered at the last of said non- <5 
preferred mobile station control queue. 


bile station, sends to said base station control- 
ler a reply to authorize priority processing, said 
reply enabling said priority-requesting mobile 
station to use a wireless channel preferentially. 

21. The packet data service node of claim 20, further 
comprising: 

a mobile station information table for register- 
ing information about priority channel usage author- 
ization. 

22. The packet data service node of claim 21 , wherein: 

said control section, upon receiving said pri- 
ority request, refers to said mobile station informa- 
tion table and sends a reply to permit priority 
processing to said base station controller rf said pri- 
ority requesting mobile station has been registered 
for priority channel usage, otherwise sends a reply 
to disallow priority processing to said base station 
controller If said priority requesting mobile station 
has not been registered for priority channel usage. 

23. A mobile communication system comprising: 

a base station controlled by a base station con- 
troller; 

at least one of a plurality of mobile stations, in 
communication with said base station using 
wireless communication channels, wherein 
said base station controller releases a wireless 
communication channel from said mobile sta- 
tion when no transmission nor reception be- 
tween said mobile station and said base station 
occurs for a time period exceeding a threshold 
period, and wherein: 

a priority-requesting mobile station re- 
questing a preferential use of a wireless 
communication channel sends a priority re- 
quest to said base station; and 
said base station controller receives said 
priority request through said radio base 
station, and upon reception of said priority 
request, said base station controller trans- 
mits acknowledgement to said mobile sta- 
tion. 


20. A packet data service node for connecting a base 
station controller with an external network, said 
packet data service node comprising: 

a control section; 
a routing section; 

a bus, connecting said routing section to said 
control section 

wherein, said control section, responsive to re- 
ceiving through said base station controller a 
priority request from a priority-requesting mo- 


24. The mobile communication system of claim 23, 
wherein: 

said mobile station transmits said priority re- 
quest periodically. 

25. The mobile communication system of claim 23, 
wherein: 

said base station controller does not release 
said wireless channel when a prior channel usage 
contract of said mobile station is registered to a 
packet data service node to which said base station 
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controller connected. 

26. A mobile communication system comprising: 

a base station controlled by a base station con- 
troller; 

at least one of a plurality of mobile stations, In 
communication with said base station using 
wireless communication channels, wherein 
said base station controller releases a wireless 
communication channel from said mobile sta- 
tion when no transmission nor reception be- 
tween said mobile station and said base station 
occurs for a time period exceeding a threshold 
period, and wherein: 

a priority-requesting mobile station re- 
questing a preferential use of a wireless 
communication channel sends a priority re- 
quest to said base 6tation; and 
said base station controller receives said 
priority request through said radio base 
station, and thereupon assigns said wire- 
less communication channel to said priori, 
ty-requesting mobile station. 

27. The mobile communication system comprising: 

a radio base station; 

a base station controller, operative to control 
said radio base station; 
at least one mobile station; wherein said at 
least one mobile station is in communication 
with said radio base station; end wherein 
said base station controller receives a wireless 
channel assignment request from said mobile 
station, which transmitted a priority request for 
requesting priority use of a wireless channel, 
and wherein, in case of shortage of wireless 
channels exists, said base station controller re- 
leases a wireless channel! rom a non-preferred 
mobile station, and assigns said released wire- 
less channel to said requesting mobile station. 
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wherein said base station controller releases said 
wireless channel upon hand-ofT of said priority re- 
quest transmitting mobile station. 

A mobile station according to claim 3, wherein said 
priority request comprises identification of a prefer- 
ential channel usage request packet. 


32. A wireless communication method for establishing 
a priority communication channel, said wireless 
communication method comprising: 

transmitting a priority request for use of a wire- 
less channel; 

setting a first timer with a timeout value less 
than a timeout value of a second timer; 
periodically transmitting said priority request at 
expiration of said first timer provided that said 
second timer has not expired; and 
wherein, responsive to said periodically trans- 
mitting said priority request, said priority use of 
said wireless channel is maintained. 

33. A wireless communication method for establishing 
a priority communication channel, said wireless 
communication method comprising: 

receiving a priority request for use of a wireless 
channel; 

determining that a priority usage of said wire- 
less channel is permissible; 
setting a timeout value to a timer; 
releasing said priority usage of said wireless 
channel at expiration of said timer unless any 
of: a periodic priority request is received, a 
transmission is received and a transmission is 
made; and 

wherein, responsive to any of: a periodic prior- 
ity request is received, a transmission is re- 
ceived and a transmission is made, said priority 
use of said wireless channel is maintained. 


28. The mobile communication system of claim 27. 
wherein said base station controller releases said 
wireless channel from said non-preferred mobile 
station which has not transmitted and/or received 
signals for a longest period. 

29. The mobile communication system of claim 27. 
wherein said base station controller releases said 
wireless channel when a prior channel usage con- 
tract of said channel assignment requesting mobile 
station is registered to a packet data service node 
to which said base station controller connected. 

30. The mobile communication system of claim 27. 


34. The wireless communication method of claim 33, 
further comprising: 

transmitting an acknowledgement responsive 
to said priority request. 

35. The wireless communication method of claim 33, 
wherein said determining that a priority usage of 
said wireless channel is permisstole further com- 
prises: 

determining that said priority request is au- 
thorized under contract for priority usage. 

36. A wireless communication method for establishing 
a priority communication channel, said wireless 
communication method comprising: 
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receiving a preferential channel assignment re- 
quest; 

determining that wireless channel resources 
are sufficient to fill said preferential channel as- 
signment request; s 
if insufficient wireless channel resources exist 
to fill said preferential channel assignment re- 
quest releasing a wireless channel from anoth- 
er communication, and assigning said released 
wireless channel to satisfy said preferential 10 
channel assignment request. 

37. The wireless communication method of claim 36, 
wherein said releasing a wireless channel from an- 
other communication further comprises : is 

releasing said wireless channel from a non- 
preferred communication which has not transmitted 
and/or received signals for a longest period. 

38. The wireless communication method of claim 36, 
further comprising: 

releasing said wireless channel upon a 
source of said preferential channel assignment re- 
quest moving to a location serviced by a different 
cell. 25 


39. A wireless communication apparatus for establish- 
ing a priority communication channel, said wireless 
communication apparatus comprising: 

means for transmitting a priority request for use 
of a wireless channel; 

means for setting a first timer with a t imeout val- 
ue less than a timeout value of a second timer; 
means for periodically transmitting said priority 
request at expiration of said first timer provided 
that said second timer has not expired; and 
wherein, responsive to said periodically trans- 
mitting said priority request, said priority use of 
said wireless channel is maintained. 

40. A wireless communication apparatus for establish- 
ing a priority communication channel, said wireless 
communication apparatus comprising: 

means for receiving a priority request for use of 
a wireless channel; 

means for determining that a priority usage of 
said wireless channel is permissible; 
means for setting a timeout value to a timer; 
means for releasing said priority usage of said 
wireless channel at expiration of said timer un- 
less any of: a periodic priority request is re- 
ceived, a transmission is received and a trans- 
mission is made; and 

wherein, responsive to any of: a periodic prior- 
ity request is received: a transmission is re- 
ceived and a transmission is made, said priority 


use of said wireless channel is maintained. 

41 . A wireless communication apparatus for establish- 
ing a priority communication channel, said wireless 
communication apparatus comprising: 

means for receiving a preferential channel as- 
signment request from a base station controller, 
and 

means for transmitting a reply to authorize said 
base station controller to assign a wireless 
channel preferentially. 

42. A computer program product for establishing a pri- 
ority communication channel, said computer pro- 
gram product comprising: 

code that transmits a priority request for use of 
a wireless channel; 

code that sets a first timer with a timeout value 
less than a timeout value of a second timer; 
code that periodically transmits said priority re- 
quest at expiration of said first timer provided 
that said second timer has not expired; and 
wherein, responsive to said periodically trans- 
mitting said priority request, said priority use of 
said wireless channel is maintained; and 
a computer readable storage medium for hold- 
ing the codes. 
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43. A computer program product for establishing a pri- 
ority communication channel, said computer pro- 
gram product comprising: 

code that receives a priority request for use of 
a wireless channel; 

code that determines that a priority usage of 
said wireless channel is permissible; 
code that sets a timeout value to a timer; 
code that releases said priority usage of said 
wireless channel at expiration of said timer un- 
less at least one of: a periodic priority request 
is received, a transmission is received and a 
transmission is made; and 
wherein, responsive to at least one of: a peri- 
odic priority request is received., a transmission 
is received and a transmission is made, said 
priority use of said wireless -channel is main- 
tained: and 

a computer readable storage medium for hold- 
ing the codes. 

44. A computer program product for establishing a pri- 
ority communication channel, said computer pro- 
gram product comprising: 

code that receives a preferential channel as- 
signment request from a base station controller. 
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and 

code that transmits a reply to authorize said 
base station controller to assign a wireless 
channel preferentially; and 
a computer readable storage medium for hold- s 
ingthe codes. 
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Abstract 

This paper presents the design of a highly available dis- 
tributed call processing system and its implementation on 
a local area network of commercial, off-the-shelf worksta- 
tions. A major challenge of using off-the-shelf components 
is meeting the strict performance and availability require- 
ments in place for existing public telecommunications sys- 
tems in a cost-effective manner. Traditional checkpointing 
and message logging schemes for general distributed 
applications are not directly applicable since call process- 
ing applications built using these schemes suffer from high 
failure-free overhead and long recovery delays. We pro- 
pose an application-level fault-tolerance scheme that takes 
advantage of general properties of distributed call pro- 
cessing systems to avoid message logging and to limit 
checkpointing overhead. The proposed scheme, applied to 
a call processing system for wireless networks, shows 
average call setup latencies of 180ms, failover times of less 
than three seconds, and recovery times of less than seven- 
teen seconds. System availability is estimated to be 
0.99995. The results indicate that using our proposed 
scheme meets the above challenge. 

1 Introduction 

Building call processing, or switching, systems in a dis- 
tributed environment of general purpose computers is 
becoming the trend of next generation switching systems 
[2][10)[J7J. Emerging distributed call processing architec- 
tures illustrate that a properly modularized and function- 
ally distributed software architecture increases system 
scalability, performance, and flexibility [9][10][17]. More- 
over, advances in open distributed processing, where the 
Common Object Request Broker Architecture (CORBA) 
[ 1 3] is one example, facilitate portable and interoperable 
implementations of distributed software architectures in a 
heterogeneous computing environment. Systems that use 
these technologies are easily able to leverage off the con- 
tinually increasing performance-to-price ratio of off-the- 
shelf computing components. 


The stringent performance and availability require- 
ments for public telecommunications systems pose key 
challenges to developing highly available distributed call 
processing systems that use off-the-shelf commodity hard- 
ware and software platforms. Call processing software 
must process each call request within a few hundred milli- 
seconds [11], and the entire switching system should not 
be out of service for more than a few minutes per year 
[18]. Existing switching systems rely on custom-designed 
fault-tolerant processors and special-purpose operating 
systems to meet these requirements. Next generation 
switching systems built using genera] purpose computing 
platforms, however, require the development of software- 
based fault-tolerance solutions which achieve the same 
performance and availability goals. 

Checkpointing and message logging strategies have 
been extensively discussed in the literature to enhance the 
level of software-based fault tolerance in a distributed 
computing environment [3] [14]. In general, a snapshot of 
the entire state of a software process is saved periodically 
(checkpointing), while messages sent or received by the 
process are logged (message logging) between check- 
points. Assuming a piecewise deterministic execution 
model, the state of the process can be reconstructed during 
recovery by replaying logged messages in their original 
order [5]. These techniques can be embedded into the 
operating system, with the advantage of being virtually 
transparent to application software [4]. 

For the reasons listed below, periodic checkpointing 
with message logging between checkpoints is not directly 
applicable to distributed call processing systems that use 
commodity components. First, large service delays due to 
periodic checkpointing of the entire state of a process will 
likely exceed call setup latency requirements during 
checkpointing. Second, the increased number of message 
exchanges required for distributed call processing makes it 
too time-consuming to log each message and still satisfy 
latency requirements. Third, periodic checkpoint intervals 
tend to be on the order of tens of minutes or more to limit 
the computational overhead of checkpointing global states; 


hence the number of logged messages to be replayed after 
a failure is large, resulting in longer recovery time and 
lower system availability. In addition, a majority of these 
replayed messages are superfluous, since the expected life- 
time of a call (around three minutes) is generally shorter 
than the checkpoint interval. 

This paper presents the design, implementation, and 
evaluation of a high performance, highly available distrib- 
uted call processing system based on commodity hardware 
and software platforms. Our primary contributions in this 
paper are: (1) the identification of general properties of 
distributed call processing systems; and (2) the develop- 
ment of an application-level fault-tolerance scheme that 
takes advantage of these properties to reduce checkpoint- 
ing overhead, avoid message logging, and shorten recovery 
time. The scheme uses object-level checkpointing, defines 
a selective event-driven checkpointing policy where check- 
points are selectively taken at different servers when cer- 
tain events occur, introduces state reloading as a technique 
to reload state in a recovering server based on redundant 
state information maintained by other servers, and con- 
ducts recovery procedures at relevant servers asynchro- 
nously. We demonstrate the effectiveness of our approach 
through measurements and analysis of our implementation 
of a call processing system for wireless networks. 
Although the above techniques have been developed for 
distributed call processing applications, these same tech- 
niques can also be applied to other classes of applications 
with similar properties (Section 3 covers this in detail). 

Hie remainder of the paper is organized as follows. 
Section 2 introduces a reference model for distributed call 
processing. The model facilitates our discussion on highly 
available distributed call processing in Section 3, which 
also presents the details of our fault-tolerance scheme. 
This scheme is applied to a distributed call processing sys- 
tem for wireless networks. Section 4 discusses the system 
architecture and its implementation. In Section 5, a perfor- 
mance evaluation of our implementation measures call 
setup latency, failure-free fault-tolerance overhead, and 
recovery time. Section 6 estimates overall system avail- 
ability, followed by concluding remarks in Section 7. 

2 Reference model for distributed call 
processing 

A telecommunications network architecture consists of 
many functional entities (FEs) that perform distinct tasks 
in the network. For example, the WIN Distributed Func- 
tional Plane defines a distributed functional model for 
wireless intelligent networks [15]. Hie model includes FEs 
that provide call control, access control, service control, 
and location registration functions. Call processing scenar- 
ios refer to various groupings of tasks coordinated through 
sequences of signaling messages. A distributed call pro- 


cessing system is a mapping of tasks to a collection of 
cooperating software modules. In general a software mod- 
ule could support tasks of multiple FEs, but only one soft- 
ware module is responsible for all tasks of a single FE. The 
modular design of functional models and its distributed 
implementation enable rapid introduction of new media 
and services over emerging transport technologies. It is 
also easier to scale up/down the capacity of a distributed 
call processing system and to enhance the capabilities of 
individual software modules. 

We define four distributed call processing terms based 
on object-oriented concepts: two object classes, functional 
object class and server class, and two object instances, 
functional object and server instance. A functional object 
class corresponds to an FE. It defines unique call process- 
ing functions supported by the class, types of physical and 
logical resources managed by the class, and interfaces 
exported to other functional object classes. A functional 
object is an instance of a functional object class. Each 
functional object manages its own assigned resources and 
associated data corresponding to a single call activity. 
Multiple functional object classes may be needed to ser- 
vice a single call processing request Each request results 
in the creation of one functional object for each of these 
functional object classes. Collectively, these functional 
objects maintain overall state information related to the 
request. The functional objects exist until the requested 
activity (e.g., a call) ends. 

A server class corresponds to a software module. It is a 
unit of computation in realizing the abstract concept of a 
functional object class in a distributed call processing 
architecture. Server classes support one or more closely 
related functional object classes. A server instance is an 
embodiment of a server class, and typically corresponds to 
a process in a real implementation. To make its capacity 
scalable, a call processing system can have multiple 
instances of the same server class. Note that the term 
server is used to represent either a server class or a server 
instance; the meaning should be clear from the context. 

As an example, Figure 1 depicts four classes of func- 
tional objects identified in our case study Mobile Switch- 
ing Center (MSQ [9] presented in Section 4: connections 
(CONN), channels (CHAN), calls (CALL), and user 
agents (UA). A CONN object performs the necessary tasks 
for establishing a single end-to-end connection and main- 
tains detailed state information about this connection. A 
CHAN object controls resource allocation activities for a 
specific transport channel resource, such as the channel of 
a switching device in the MSC. A CALL object records 
call activities of a specific user, while a UA object main- 
tains non-call-related state information about the user 
(such as a user's service profile). Note that UA and CALL 
are user-specific, a CONN is unique for each connection, 



UA obj: User Agent object /^=S^^S^ 

CALL obj: Call object H( CHANobi ^ 

CONN obj: Connection object x 

CHAN obj: Channel object 

Figure 1. Functional objects for distributed call 
processing 

and a CHAN is for a particular resource. Thus, UA and 
CALL object classes are good candidates for being 
grouped together within one server class. 

3 Design for highly available distributed call 
processing systems 

As stated in the introduction, an operating system level 
fault-tolerance approach has three major obstacles (global 
state checkpointing, frequent message logging, and long 
message replaying) to meeting the stringent performance 
and availability requirements for distributed caJl process- 
ing systems. Consequently, we use an application-level 
fault-tolerance solution [4][5]. This approach, although not 
transparent to application software, allows significantly 
finer control over when and what data to checkpoint, and 
how to perform recovery. Our goals are: (l) to perform 
checkpointing at a fine granularity to avoid long check- 
pointing times; and (2) to eliminate message logging, 
thereby reducing failure-free overhead and expediting 
recovery procedures. In this section, we describe our fault- 
tolerance scheme, which is derived by exploiting proper- 
ties common to distributed caJl processing systems. After 
stating the requirements for call processing systems, we 
describe our checkpointing and recovery strategies. 

3.1 Requirements 

Public telecommunications switching systems have 
been designed to meet stringent availability requirements 
due to a large societal dependence on their service: only a 
few minutes of downtime per year are tolerated [ 1 8]. Since 
we cannot prevent failures from occurring, recovery times 
must be short to minimize service down time. In addition, 
any design of highly available distributed call processing 
systems must satisfy the following requirements: 
Rl. High performance: Low end-to-end call setup times 
(less than a few hundreds milliseconds) are required 
[11]. This constraint must be satisfied even with pro- 
visions for high availability. 
R2. Active call preservation: Active calls must be pre- 
served across failures. Calls in a transient state, on 
the other hand, need not be preserved, but may be 


retried or cleared. Clearing transient calls is a com- 
mon practice in telecommunications systems. 
R3. Resource leak avoidance: Reserved system resources 
must be released even if a call request is abnormally 
aborted due to a failure. 

3.2 Object-level checkpointing 

Our fault-tolerance scheme takes checkpoints per func- 
tional object instead of per process, which we call object- 
level checkpointing. The following general property of call 
processing supports this approach: 
Property J: Functional objects are independent and small 
in size. 

Since a call activity involves only one functional object 
per functional object class, there is no mutual dependency 
among functional objects of the same class. Thus, check- 
pointing can be scheduled per object without coordinating 
with other objects in the class. Since call processing sys- 
tems in public telecommunications networks can handle a 
large amount of call signaling traffic, a process may con- 
tain thousands of functional objects 1 . Each checkpoint thus 
contains only a tiny fraction of the entire process state. 

Even if checkpoints are taken per object, message log- 
ging is still required to recover from lost messages. Due to 
the following property of call processing systems, how- 
ever, we can completely eliminate message logging: 
Property 2: Call processing systems are surrounded by 
robust standard signaling interfaces. 

Switching systems of different vendors and in different 
networks must interwork through standard signaling inter- 
faces. Signaling protocols for these interfaces have been 
designed with high reliability in mind; detecting lost 
request or response messages and invoking appropriate 
recovery actions are all part of the protocols. Timeout 
mechanisms are commonly used to detect failures. Upon 
timer expiration, a lost request is either retried or aborted, 
depending on the situation. Therefore, neither message 
logging nor message replay is necessary, resulting in lower 
failure-free overhead and reducing recovery time. 

33 Checkpointing policy 

An important design choice for object-level checkpoint- 
ing is determining when to checkpoint a functional object. 
The most intuitive approach is to checkpoint the object 
whenever its state changes (due to a message receipt). 
Since many message exchanges are involved in a single 
call setup request, however, this method significantly 
degrades failure-free performance. A more suitable check- 
pointing policy is therefore needed. 


1 . For example, consider a local switch that can process 200K calls per 
hour. Assuming a 3-minute call holding time, on average ten thousand 
calls (and CONN/CALL objects) ate active at a given time. 



Figure 2. Typical state machine In call processing 
systems 

Before developing our checkpointing policy, let us 
review the structure of typical call processing software to 
determine where and when to best perform checkpointing. 
A characteristic feature of call processing systems is the 
asynchronous nature of events. Since multiple parties are 
involved in a call, two independent and sometimes con- 
flicting, events may simultaneously affect a single func- 
tional object. For example, a caller might hang up while 
connections are being setup for the call. Upon arrival of 
such an interruptive event, it may be necessary to abort 
ongoing procedures for the original request 

To cope with asynchronous event arrivals, a state 
machine model is employed for telecommunications sys- 
tems. Figure 2 shows a typical state machine for call pro- 
cessing systems. Two stable states, null state and active 
state, exist along with many other transient states. For the 
CONN object introduced in Section 2, for example, the 
active state represents the state where an entire connection 
is established between end users, while the null state 
means that there is no connection. The transient states for a 
CONN object are the states where the connection is being 
setup or torn down. The following observation of transient 
states supports our checkpointing policy: 
Observation: Only a small number of calls are in a 
transient state. 

Since call establishment and call release procedures 
take only a few hundred milliseconds compared to average 
call durations, which are on the order of minutes, most call 
activities are in stable states. 

Based on the above properties of distributed call pro- 
cessing systems, we describe our checkpointing policy, 
called selective event-driven checkpointing. The policy 
omits as many checkpoints as possible, except where omit- 
ting a checkpoint violates two of the requirements dis- 
cussed in Section 3.1, namely active call preservation (R2) 
and resource leak avoidance (R3). Checkpoints are taken 
only when: 

1 . committing to a stable state, and 

2. obtaining new state information required to undo 
resource allocation or to redo resource clearing. 


In our approach, all objects in a transient state within a 
failed server instance are cleared. Since most calls are in 
stable states, only a small number of calls are affected by 
the above checkpointing policies. 

The following observation for distributed call process- 
ing systems makes it possible to further reduce the number 
of checkpoints: 

Property 3: Partial state information is replicated among 
multiple objects of different functional object classes. 

When functional objects are contained within different 
servers, replicated state information may exist among the 
servers so that a functional object in one server can iden- 
tify an appropriate functional object in another server. We 
avoid redundantly checkpointing the same data by desig- 
nating one server to be responsible for checkpointing the 
state information shared by the servers. After a failure, a 
recovering server that does not checkpoint the shared state 
'reloads' its state information from servers that do check- 
point the state. We call this procedure state reloading. 
State reloading reduces the number of checkpoints in the 
system, reducing failure-free fault-tolerance overhead. 

We distinguish pessimistic state reloading (PSR) from 
optimistic state reloading (OSR). In PSR, new call setup 
requests that arrive at a recovering server before state 
reloading completes are discarded. In OSR, new call setup 
requests that arrive at a recovering server are processed 
while state reloading is being performed, based on the 
assumption that call setup requests do not arrive for users 
that are already in a call. Thus, OSR decreases system 
recovery time as compared to PSR. Occasionally, the 
above assumption may not be satisfied, resulting in con- 
flicting state information. When this occurs, ongoing call 
request procedures for the conflicting call must be aborted. 

3.4 Call recovery strategy 

During recovery, a recovering server instance must 
either undo or redo unsuccessful call setup and release 
attempts, detect state inconsistencies, and resynchronize 
the states of related objects among distributed servers. 
Since our fault-tolerance scheme is performed at the appli- 
cation level, these recovery mechanisms must also be real- 
ized at the application level. Incorporating these 
mechanisms for fault tolerance is easy since most of the 
required recovery procedures are already present in normal 
call processing flows. 

Recall from Figure 2 that there are two main phases in 
processing call requests. The resource allocation phase 
reserves network resources in stages during the transition 
from a null state to an active state. The resource release 
phase returns the call processing state machine to a null 
state from an active state by freeing reserved resources. 
Additional state transitions exist from transient states in 
the resource allocation or resource release phase to states 


in the resource release phase. They embody an abort action 
triggered by an interruptive event like a timeout or hang-up 
by a caller. Since such events may occur asynchronously 
with respect to the current state, call processing systems 
are required to provide abort recovery procedures for each 
functional object from any state. Furthermore, an interrup- 
tive event at one server may cause inconsistencies among 
the states of related functional objects in different servers. 
Thus, distributed call processing software must provide a 
global ^synchronization procedure to resynchronize the 
states of the related objects. Abort messages which initiate 
abort recovery procedures for a functional object may be 
used for this purpose. Due to the asynchronous arrival of 
such events, the precise state of an interrupted resource 
reservation request, for example, is unknown, and it is 
uncertain if the request is granted or not. Therefore, abort 
recovery operations must be idempotent, namely, carrying 
them out several times has the same effect as carrying 
them out once [ 1 2]. To summarize: 
Property 4: Distributed call processing systems famish 
idempotent operations, abort recovery procedures, and 
global resynchronizfltion procedures. 

Given Property 4, only minimal effort is required to 
support recovery from failures, lb avoid resource leaks, a 
recovering server instance must initiate abort recovery 
procedures for functional objects that are in transient states 
and invoke system-wide resynchronization procedures as 
necessary. The idempotent resource release operations per- 
mit fewer checkpoints to be taken during call setup and 
call release, with no adverse effects of unnecessarily reis- 
suing release requests during recovery. 

3.5 Primary and backup configuration 

To further shorten recovery time after a failure, a pri- 
mary-backup approach is used for each server instance [8], 
as opposed an approach that checkpoints state information 
to disk, lb survive a single host failure, the primary and its 
backup execute on different hosts. The primary server 
instance processes all incoming requests and checkpoints 
state information to its backup, as necessary. Since a 
backup server is already executing when a primary failure 
occurs, server unavailability is reduced due to shorter 
failover times. 

4 Case study: Mobile Switching Center 

This section applies the ideas of functionally distributed 
call processing and the general techniques for high avail- 
ability, as described in the previous two sections, to a call 
processing system for wireless networks, called a Mobile 
Switching Center (MSC) [9]. After providing background 
information on mobile switching centers, we present our 
MSC architecture, the checkpointing and reloading strate- 
gies, and the failure detection and recovery mechanisms. 


4.1 Background 

An MSC is a local switching facility in a wireless net- 
work. Each MSC controls mobile traffic in a service area 
divided into geographical regions called cells. A Base Sta- 
tion (BS) within each cell manages radio resources 
between itself and all Mobile Stations (MS) roaming 
within the cell. All BSs in an MSCs service area have 
wired links to the MSC, which in turn connects to other 
MSCs and to the Public Switched Telephone Network 
(PSTN). A Home Location Register (HLR) is connected to 
the PSTN and keeps a global database identifying which 
MSC is responsible for setting up calls to a particular MS. 
The procedure of locating an MS within an MSCs service 
area during call setup is called paging. 

An MSC performs two key functions: call processing 
and mobility management. Call processing involves setting 
up and tearing down connections between calling and 
called parties. Mobility management includes power-up 
and power-down registration of MSs, resulting in updates 
to the MS's location information in the corresponding 
HLR, and paging mobile stations during call setup. 

4.2 Highly available MSC architecture 

Figure 3 illustrates our MSC architecture. There are 
four classes of call processing servers and three classes of 
management servers. Note that multiple instances of each 
server class may exist in an actual system. 



USS: User Signaling Server 
ConnSrv: Connection Server 
CM: Configuration Manager 
PMon: Process Monitor 


ChanSrv: Channel Server 
IM: Interworking Manager 
EM: Event Manager 


Figure 3. MSC call processing software structure 

4.2.1 Call processing servers. Interworking managers 
(IMs) act as protocol gateways to internal MSC servers, 


isolating them from external signaling protocols and 
thereby allowing the MSC to evolve independent of these 
protocols. An IM may terminate one or more signaling 
protocols and one or more types of IMs may exist within 
an MSC. Functional objects within an IM record mapping 
information between identifiers, such as call id, used both 
internal and external to the MSC to correlate call 
processing activities. 

A user signaling server (USS) maintains information in 
UA objects about the registration status of mobile stations 
currently roaming within the service area of the MSC. A 
USS also houses CALL objects, each recording call activi- 
ties involving a particular mobile station. 

Channel servers (ChanSrvs) maintain CHAN objects to 
manage switching device resources allocated during call 
setup and deallocated during call release. Examples of 
resources include the switching fabric used to setup physi- 
cal connection segments and voice encoders/decoders that 
take packet data from the wireless link (air interface) and 
convert it to pulse code modulated voice and vice versa. 

A connection server (ConnSrv) coordinates allocation 
of channel resources to setup a connection to the BS of the 
cell in which the MS is currently roaming. The ConnSrv 
instructs appropriate ChanSrvs to reserve needed MSC 
channel resources and sends messages to external compo- 
nents via IMs to reserve channel resources external to the 
MSC. Each ConnSrv maintains detailed state information 
about a single connection for an MS in a CONN object. 

4.2.2 Management servers. A Process Monitor (PMon) 
detects failures of both server instances and processors. An 
Event Manager (EM) collects failure reports from PMons, 
performs fault isolation, and informs a Configuration 
Manager (CM) of actual failures. The CM coordinates 
appropriate system-wide recovery actions, including 
necessary reconfiguration activities; it also performs 
overall system initialization. 

43 Checkpointing and state reloading strategies 

The various call processing servers described above use 
different strategies for checkpointing and state reloading. 
ConnSrvs perform selective event-driven checkpointing of 
CONN objects using the checkpoint policy described in 
Section 3. Since all ConnSrv state is contained within 
CONN objects, state reloading is not needed. USSs per- 
form selective event-driven checkpointing of UA objects 
and OSR for CALL objects. CALL objects can be derived 
from corresponding UA and CONN objects. PSR is used 
for CHAN objects to ensure that channel resources allo- 
cated before a ChanSrv failure are not mistakenly reallo- 
cated during recovery. CHAN objects can be recreated 
from information in CONN objects. The IMs in our archi- 


tecture are stateless and therefore require no checkpointing 
or state reloading. 

4.4 Failure detection and recovery 

Process crashes and hangs are two major causes of pro- 
cess failures [4]. The former can be immediately detected 
by a PMon as an underlying connection break (e.g. TCP/IP 
connection) with the failed process, typically within a hun- 
dred milliseconds. Detecting process hangs is achieved by 
PMons periodically exchanging "keep alive" messages 
with each process. An unsuccessful "keep alive" message 
exchange indicates a potential failure of the process. We 
refer to this periodic message exchange interval as the 
keep-alive interval. The keep-alive interval determines 
failure detection time. We assume that PMons are very 
reliable and so do not fail unless the underlying processor 
fails. Then, detecting processor failures only requires us to 
detect PMon failures. To achieve this, PMons are deployed 
on all host machines and monitor each other using a 
(dynamic) testing assignment as described in [1][4], 

Once a failure is detected, recovery actions are initiated. 
The following list enumerates the recovery steps that occur 
following the hang of a primary server instance (process) 
that uses PSR: 

1. The PMon reports the unsuccessful "keep alive" 
message exchange to EM; 

2. EM performs fault isolation to identify the server 
instance that has failed; 

3. This failure is reported to the CM, which coordi- 
nates all remaining recovery actions; 

4. Signaling connections are established between the 
failed server instance's backup and all server 
instances originally communicating with the failed 
server instance; 

5. State reloading procedures are initiated in the 
backup server instance, if necessary; 

6. Once state reloading is complete, the backup server 
instance becomes a primary server instance. This 
new primary commences state resynchronization 
procedures and starts accepting new incoming call 
processing messages. Call processing messages that 
arrive before this step are discarded; 

7. After the new primary becomes available, a new 
backup server instance is instantiated; 

8. The new primary checkpoints its entire state to the 
new backup. This procedure is referred to as check- 
point dumping. 

For recovery after backup server instance failures, steps 
1 -3, 7 and 8 are executed. Recovery actions initiated by the 
failure of a primary server instance that uses OSR take the 
same steps, except that the backup becomes a primary after 
step 4 and incoming calls that arrive during state reloading 
are processed instead of discarded. 


4.5 Implementation 

An implementation of our MSC architecture executes 
on a collection of UNIX workstations interconnected via a 
local area network. Each MSC call processing server is 
implemented as a UNIX process. Inter-process communi- 
cation between MSC servers uses Iona's Orbix [6], a 
CORBA-based middleware platform. Server instances are 
implemented as CORBA objects, while functional objects 
arc realized as C++ objects. The MSC implementation 
includes three classes of IMs to support standard telecom- 
munications signaling interfaces: an IS-634A interface 
with base stations [16]; an IS-4I interface with an HLR 
[15]; and an ISDN User Part interface with PSTN switch- 
ing nodes [7J. A single class of channel servers executes 
on an embedded system that provides frame selection and 
voice encoding/decoding capabilities. 

In our implementation, a mobile station registration 
scenario involves four CORBA message exchanges within 
MSC servers and a single checkpoint when the registration 
state (powered up or powered down) changes. Processing a 
call setup request originated from a mobile station, i.e. a 
call origination scenario, involves nine CORBA message 
exchanges and three checkpoints, while a call setup 
request coming from PSTN, i.e. a call termination sce- 
nario, requires seventeen CORBA message exchanges and 
two checkpoints. A call release request involves nine 
CORBA message exchanges and two checkpoints. Note 
that our proposed scheme requires only 25% of all state 
transitions due to message arrivals to be checkpointed, 
considerably reducing failure-free overhead compared to 
traditional approaches. 

5 Performance evaluation 

This section presents the results of a performance eval- 
uation of our MSC implementation. Failure-free overhead 
and recovery times after failures are discussed. 

5.1 Experimental environment 

The MSC hardware platform used in our experimenta- 
tion consists of two SUN Ultra 2 workstations, each hous- 
ing a single 200 MHz UItraSPARC-I processor, 
interconnected via a 10 Mbps Ethernet. The MSC software 
configuration consists of two instances each of the USSs 
and ConnSrvs, one PMon instance per workstation, and 
one instance each of the other MSC call processing and 
management servers. We distribute all server instances, 
including backups for each primary call processing server, 
across the two workstations. Two simulators are employed 
to generate user registration and call processing traffic, one 
to simulate a BS and the other to simulate the HLR and 
PSTN switching nodes. The simulators execute on sepa- 
rate UltraSparc workstations and exchange call processing 
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Figure 4. Failure-free overhead: latency versus load 
with and without checkpointing 

messages with the MSC via TCP/IP connections to the 
IMs. In our experiments, a Poisson distribution models 
registration and call request arrival traffic. An exponential 
distribution models call holding time. 

5.2 Failure-free overhead 

To evaluate the failure-free checkpointing overhead of 
the MSC, we measured call setup latencies of our experi- 
mental configuration both with and without checkpointing 
to backup servers. We assume 40,000 registered mobile 
stations and a 90-second average call holding time. Perfor- 
mance with several call arrival rates are examined, while 
the ratio of originating to terminating calls is kept fixed at 
a ratio of approximately two-to-one. Power-up registration 
for all mobile stations is performed in advance of the per- 
formance evaluation, although registration traffic for hand- 
offs does take place during the measurement period. This 
handoff registration traffic does not incur any checkpoint- 
ing at the USSs. In the experiments, call setup latency is 
measured at the two simulators since this reflects the delay 
incurred within the MSC as perceived by end users. 

Figure 4 shows the average call setup latency versus 
call load. The curve has a knee when the latency goes 
beyond 180 milliseconds. At the knee, call throughput is 
120K calls/hour with fault-tolerance support (180K calls/ 
hour if checkpointing is not performed). This represents 
the maximum call throughput for the given system config- 
uration; beyond this call throughput, the MSC becomes 
overloaded. Note that checkpointing to backup processes 
reduces call throughput by 33%. 

S3 Recovery time 

Table 1 summarizes the mean recovery time at 120K 
calls/hour for crash failures of the primary instances of the 
various MSC servers. For illustration purposes, recovery 
times for primary USS failures are presented both for PSR 
and OSR. Forty samples are collected for each case. 
Hmestamps were taken by the CM at four different events 


Failed Primary 
Server 

USSw/ 
PSR 

USSw/ 
OSR 

Conn 
Srv 

IM 

Chan 
Srv 

ReconnDoneTime (s) 

0.29 

0.27 

0.16 

0.15 

0.20 

ReloadDone Time (s) 

1.73 

2.13 

0.20 

0.18 

2.53 

DumpChkptTtme (s) 

5.10 

5.95 

4.09 



DumpDoneTime (s) 

16.33 

16.46 

5.15 




TABLE 1 . Recovery Time at 120K Calls/Hour 


during recovery, relative to the time when the failure is 
first reported to the CM. These events are described below. 
Note that worst case recovery times are within 5% of the 
mean values indicated in Table 1. 

ReconnDoneTime identifies the time when all lost sig- 
naling connections between the failed primary and other 
server instances are re-established with the backup. For 
ConnSrvs and USSs operating with OSR, the backup 
server instance is activated (becomes the new primary) at 
this point, and new caU requests can be accepted. Reload- 
DoneTime identifies when state reloading is complete. For 
USSs with PSR, new call processing messages can be 
accepted after this point. For ConnSrv failures, the time 
between ReconnDoneTime and ReloadDoneTime is used 
to initiate ^synchronization procedures for transient 
objects in the failed server. Due to the small number of 
transient calls in the system, this time difference is small. 
For USS failures, the difference between ReconnDone- 
Time and ReloadDoneTime is greater for OSR than for 
PSR since, for OSR, new call requests are accepted and 
processed during state reloading of CALL objects from the 
ConnSrvs. Our experimentation shows that OSR results in 
a 75% reduction of lost calls over PSR. 

Approximately 3.5 seconds elapse between Reload- 
DoneTime and DumpChkptTtme for the CM to create a 
new backup. process. DumpChkptTime identifies the time 
at which the primary performs checkpoint dumping to 
store a copy of its state information at the new backup, and 
DumpDoneTime indicates when this procedure has com- 
pleted. At a load of 120K calls/hour using a 90-second call 
holding time, each USS houses approximately 20,000 UA 
objects which must be downloaded during this time (corre- 
sponding to 2MB of data), while a ConnSrv contains only 
1,500 CONN objects. This explains why roughly ten sec- 
onds are needed to checkpoint complete USS state infor- 
mation, compared to just over one second for ConnSrv 
failures. After DumpDoneTime, i.e. 5 to 17 seconds after 
the failure is reported to CM, the system is ready for the 
next failure of this specific server instance. 

The short recovery times observed in our experimenta- 
tion contribute to the high overall system availability 
derived in the following section. 


6 Availability analysis 

This section presents a preliminary availability analysis 
for our MSC prototype. We calculate MSC availability 
based on the number of lost calls, rather than the time that 
components of the MSC are unavailable, since lost calls 
represent a more useful metric of lost revenue in telecom- 
munications call processing systems. The same MSC sys- 
tem configuration used in the performance evaluation 
(Section 5) is employed in this analysis. 

USS recovery uses OSR, while ChanSrv recovery uses 
PSR. Call processing load at a particular type of server is 
assumed to be evenly distributed among all instances of 
the server. Although call arrival rates vary throughout the 
day, we take a conservative assumption that failures occur 
only during busy hours. We further assume that sufficient 
processing capacity exists within the MSC so that overall 
performance can be maintained during failover. 

In our analysis, the following assumptions are made 
about the failure model. These assumptions allow us to 
determine MSC availability based on the experimental 
data presented in Section 5.3. 

• Process hangs, operating system hangs, and processor 
crashes are considered 2 . 

• Communication device failures are not considered. 

• Failures are independent. 

• Multiple simultaneous failures do not occur.. 

• Recovery completes before the next failure occurs 3 . 
Furthermore, the following conservative assumptions 

on failure rates are used in our availability calculation: 

• Each process fails (independently) once every other 
week. 

• The operating system on each processor hangs once 
every two months. 

• Each processor fails once every 18 months. 

6.1 Lost calls resulting from process failures 

There are three sources of lost calls resulting from fail- 
ures: transient lost calls, discarded calls, and abandoned 
calls. Transient lost calls are the calls that are being setup 
when a process failure occurs. After the failure but before 
a new primary process becomes ready, all newly arrived 
calls are discarded; we refer to these as discarded calls. 
Finally, in our implementation, checkpointing all state 
information from a primary process to a new backup pro- 


2. Our analysis assumes that process hangs are the only source of process 
failures. Since it takes a considerably longer time to detect a process hang 
than a process crash, our availability analysis will give us a more conser- 
vative result Processor crashes require a similar fault detection period. 

3. For processor failures, recovery does not imply that the failed proces- 
sor is repaired before the next process failure occurs. It is assumed, how- 
ever, that failed processors do get repaired and are reintegrated into the 
system (without disrupting call processing) before a subsequent operating 
system or processor failure. 


cess during recovery prevents the primary process from 
accepting new requests. These new requests are not dis- 
carded but blocked at the input message queue of the pri- 
mary process for the duration of checkpoint dumping. If 
call setup is not performed sufficiently quickly, a user may 
abort the call request We refer to these calls as abandoned 
calls and capture this phenomenon in our analysis by a 
patience probability function p(t) , defined as the proba- 
bility that a user hangs up a call at time f. In this analysis, 
we assume that a user always abandons a call if the call 
does not complete within a threshold time /^from the cor- 
responding call request Thus, the patience probability 
function p(t) equals the delta function 5(r rw ) such that 
Jo S('r#) = 1 \ft^t TH , and 0 otherwise. 

Let X MSC and X Sj denote the average call arrival rates at 
the MSC and at a primary server process J, of server class 
s, respectively. If n s represents the total number of 
instances of servers of class s, then X Sf = X M5C /n s . Let 
t DT be the time interval from a failure to its detection. For 
process hangs, t m is one half of a keep-alive interval on 
average. Furthermore, let t RO t Rb and t DM denote aver- 
age values of call setup latency, ReconnDoneTime, time 
required for state reloading (ReloadDoneTime - 
ReconnDoneTime\ and time required to dump checkpoint 
data (DumpDoncTtme - DumpChkptTime\ respectively. 
Then, the total number of lost calls due to failure of a pri- 
mary server process s b LC S( , is given by: 

(EQ1) 

where the indicator variable S PSR equals 1 (0) if PSR 
(OSR) is used. The first term in Equation 1 corresponds to 
the number of transient lost calls, the second term repre- 
sents the number of discarded calls, and the third term is 
the number of abandoned calls. When calculating the num- 
ber of transient lost calls, a call is considered transient until 
call setup procedures have completed within the MSC. 
Call discarding occurs at three time intervals during pro- 
cess failure and recovery: before the failure is detected, 
after failure detection but before inter-process connections 
are re-established, and, if PSR is used, while state reload- 
ing is in progress. The terms in parenthesis in the second 
term of Equation 1 correspond, respectively, to these three 
time intervals. Note that only abandoned calls contribute to 
lost calls when backup processes fail. 

Table 2 presents the number of lost calls due to failures 
of the primary and backup server processes at \ MSC =1 20K 
calls/hour. We obtain t LT = 180 milliseconds from Figure 4 
and use a keep-alive interval of ten seconds (average pro- 
cess failure detection time t DT = 5 seconds). t RO t RU and 
t DM are taken from Table 1 . We also use t TH = 5 seconds. 

The table indicates that the two major causes of lost 
calls are discarded calls due to long failure detection times 
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3.00 

8333 

4.50 

0.00 

92.17 

183.00 
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2 

3.00 

83.33 

2.67 

0.00 

0.00 
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6.00 

166.67 

5.00 

0.00 

0.00 

177.67 

ChanSrv^ 
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6.00 

166.67 

6.67 

84.33 

0.00 

263.67 
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6150 
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5.27 

23.04 

9531 


TABLE 2. Lost Calls Per MSC Server Process Failure 

and abandoned calls. Effects of the former can be reduced 
by shortening the keep-alive interval, with a resulting 
increase in keep-alive message traffic and a higher possi- 
bility of misinterpreting traffic congestion as a failure. 
Increasing the number of primary instances of a server is 
another approach, since distributing the call request load 
among more instances implies that each instance services, 
on average, fewer calls. For example, with twice as many 
USSs as IMs in the configuration, failure detection rime 
contributes half as many lost calls for a USS failure as for 
an IM failure, as shown in the \t DT column of Table 2. 

Abandoned calls resulting from USS failures are due to 
the long checkpoint dumping time needed to transfer UA 
object state from a primary USS to its backup. This time 
can be reduced by increasing the number of USS instances 
so that each USS instance manages fewer UA objects. 

6.2 Lost calls due to operating system and 
processor failures 

Both operating system and processor failures mean that 
all processes executing on the failed platform must be 
migrated to another processor, with primary-to-backup 
failovers occurring as necessary to speed up recovery time. 
The difficulty in calculating the number of lost calls is in 
identifying which processes must be failed over as well as 
the failover duration. Thus, we take the following conser- 
vative approach, assuming that recovery can proceed in 
parallel for each failed server instance: let S be the set of 
all server classes in the MSC and let n = min(n,| s e S) . 
Thus, one n-ih of transient calls and one n-th of all newly 
arriving calls will be affected until the longest recovery 
sequence completes, namely from the failure to Dump- 
DoneTtme. Let t DD be the largest DumpDoneTime. Then, 
the total number of calls lost during failover due to operat- 
ing system and hardware failures, LC OH% is estimated by: 

!<Coh = W('tr + *ot + W'* < EQ 2 ) 

At 

^■MSC = 120 K calls/hour, tu = 180 milliseconds 
(from Figure 4) and t OD = 16.48 seconds (from Table 1). 
Setting n = 1 and using t OT = 5 seconds, we obtain 
LC OH = 722 lost calls. 


63 Availability calculation 

Table 3 summarizes the number of lost calls per year 
due to various MSC component failures by using the fail- 
ure rate assumptions noted at the beginning of Section 6. 
The availability is then easily calculated as (1 - total lost 
calls / attempted calls). Assuming a call arrival rate of 
120K calls per hour, each and every day, 52 weeks a year, 
the analysis yields an MSC availability of 0.99995. This is 
in line with existing requirements for MSC availability. 


MSC Component 

Failures 

Component 
per Year 

Component 
Quantity 

Lost 
Calls 

per 
Failure 

Total 
Lost 
Calls/ 
Year 

MSC Server Process 

26.00 

'( 16 

9531 
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Operating System 

6.00 

2 

722.00 

8664.00 

Processor 

0.67 

2 

722.00 

967.48 

TOTAL 
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TABLE 3. Number of Lost Calls Per Year Based on 
MSC Component Failure 


7 Conclusion 

This paper presented the design, implementation, and 
evaluation of a highly available distributed call processing 
system based on commercial computing platforms. Call 
processing software is partitioned into functionally distinct 
servers, and software-based fault tolerance solutions are 
used exclusively to provide high availability. The use of 
object-level checkpointing, a selective event-driven check- 
pointing policy, and state reloading addresses the key chal- 
lenge of meeting stringent availability and performance 
requirements simultaneously. Our scheme leverages off 
properties common to distributed call processing systems 
to reduce checkpointing overhead, avoid message logging, 
and shorten recovery time. It also requires less recovery 
coordination for resynchronizing states of relevant servers. 

The proposed scheme was applied to a call processing 
system for wireless networks and implemented for opera- 
tion using a local area network of UNIX workstations and 
CORBA as the communication middleware. The imple- 
mentation, based on only two UltraSPARC-I processors 
connected via a 10 Mbps Ethernet, achieves a call handling 
capacity of 120K calls/hour with an average call setup 
delay of 180 milliseconds. Only one-fourth of all system- 
wide state changes are checkpointed using our selective 
event-driven checkpointing policy, with no resource leak- 
age when failures occur. Failure-free overhead was mea- 
sured to be 33%. Failover is fast, occurring within three 
seconds for single process failures, while total system 
recovery completes within seventeen seconds. Using pessi- 
mistic assumptions about the failure rates of software pro- 
cesses, operating systems, and processors, overall system 
availability is estimated to be 0.99995. This work demon- 


strates that it is feasible to build distributed call processing 
systems using off-the-shelf components that meet the strin- 
gent performance and availability requirements in place 
for existing custom-built systems. 
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